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Abstract 

Distributed implementations of access control abound in distributed storage proto- 
cols. While such implementations are often accompanied by informal justifications 
of their correctness, our formal analysis reveals that their correctness can be tricky. 
In particular, we discover several subtleties in a state-of-the-art implementation 
based on capabilities, that can undermine correctness under a simple specification 
of access control. 

We consider both safety and security for correctness; loosely, safety requires 
that an implementation does not introduce unspecified behaviors, and security re- 
quires that an implementation preserves the specified behavioral equivalences. We 
show that a secure implementation of a static access policy already requires some 
care in order to prevent unspecified leaks of information about the access policy. 
A dynamic access policy causes further problems. For instance, if accesses can be 
dynamically granted then the implementation does not remain secure — it leaks in- 
formation about the access policy. If accesses can be dynamically revoked then the 
implementation does not even remain safe. We show that a safe implementation is 
possible if a clock is introduced in the implementation. A secure implementation 
is possible if the specification is accordingly generalized. 

Our analysis shows how a distributed implementation can be systematically de- 
signed from a specification, guided by precise formal goals. While our results are 
based on formal criteria, we show how violations of each of those criteria can lead 
to real attacks. We distill the key ideas behind those attacks and propose correc- 
tions in terms of useful design principles. We show that other stateful computations 
can be distributed just as well using those principles. 



1 Introduction 

In most file systems, protection relies on access control. Usually the access checks are 
local — the file system maintains an access policy that specifies which principals may 
access which files, and any access to a file is guarded by a local check that enforces the 
policy for that file. In recent file systems, however, the access checks are distributed, 
and access control is implemented via cryptographic techniques. In this paper, we try 
to understand the extent to which these distributed implementations of access control 
preserve the simple character of local access checks. 
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We focus on implementations that appear in file systems based on networked stor- 
age fl3l . In such systems, access control and storage are parallelized to improve per- 
formance. Execution requests are served by storage servers; such requests are guided 
by access requests that are served elsewhere by access-control servers. When a user 
requests access to a file, an access-control server certifies the access decision for that 
file by providing the user with an unforgeable capability. Any subsequent execution 
request carries that capability as proof of access; a storage server can efficiently verify 
that the capability is authentic and serve the execution request. 

We formally study the correctness of these implementations vis-a-vis a simple spec- 
ification of local access control. Implementing static access policies already requires 
some care in this setting; dynamic access policies cause further problems that require 
considerable analysis. We study these cases separately in Sections [2] and [3] Based on 
our analysis, we develop formal models and proofs for an implementation of arbitrary 
access policies in Section|6] 

We consider both safety and security for correctness; loosely, safety requires that an 
implementation does not introduce unspecified behaviors, and security requires that an 
implementation preserves the specified behavioral equivalences. Our proofs of safety 
and security are built modularly by showing simulations; we develop the necessary 
definitions and proof techniques in Section [4] 

Our analysis shows how a distributed implementation can be systematically de- 
signed from a specification, guided by precise formal goals. We justify those goals by 
showing how their violations can lead to real attacks (Sections [2] and [3}. Further, we 
distill the key ideas behind those attacks and propose corrections in terms of useful 
design principles. We show that other stateful computations can be distributed just as 
well using those principles (Section[7]). 

Comparison with related work This paper culminates a line of work that we begin 
in 1 10 1 and continue in ifTTI . In iflOl . we show how to securely implement static access 
policies with capabilities; in IfTTI . we present a safe (but not secure) implementation of 
dynamic access policies in that setting. In this paper, we carefully review those results, 
and systematically analyze the difficulties that arise for security in the case of dynamic 
access policies. Our analysis leads us to develop variants of the implementation in IfTTI 
that we can prove secure with appropriate assumptions. The proofs are built by a new, 
instructive technique, which may be of independent interest. 

Further, guided by our analysis of access control, we show how to automatically de- 
rive secure distributed implementations of other stateful computations. This approach 
is reminiscent of secure program partitioning [22|. 

Access control for networked storage has been studied in lesser detail by Gob- 
ioff 03 1 using belief logics, and by Halevi et al. lfT31l using universal composability (9). 
The techniques used in this paper are similar to those used by Abadi et al. for secure 
implementation of channel abstractions \2\ and authentication primitives y], and by 
Maffeis to study the equivalence of communication patterns in distributed query sys- 
tems ifrTll . These techniques rely on programming languages concepts, including test- 
ing equivalence [21 j and full abstraction fT9l [T|. A huge body of such techniques have 
been developed for formal specification and verification of systems. 
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We do not consider access control for untrusted storage lfl6l in this paper. In file 
systems based on untrusted storage, files are cryptographically secured before storage, 
and their access keys are managed and shared by users. As such, untrusted storage is 
quite similar to public communication, and standard techniques for secure communi- 
cation on public networks apply for secure storage in this setting. Related work in that 
area includes formal analysis of protocols for secure file sharing on untrusted storage 
|[T8l l8l. as well as correctness proofs for the cryptographic techniques involved in such 
protocols 1171 [121 151. 

2 Review: the case of static access policies 

To warm up, let us focus on implementing access policies that are static. In this case, 
a secure implementation already appears in ifTUl . Below we systematically reconstruct 
that implementation, focusing on a detailed analysis of its correctness. This analysis 
allows us to distill some basic design principles, marked with bold R, in preparation for 
later sections, where we consider the more difficult problem of implementing dynamic 
access policies. 

Consider the following protocol, NS S , for networked storageQ Principals include 
users U, V, W . . ., an access-control server A, and a storage server S. We assume that 
A maintains a (static) access policy F and S maintains a store p. Access decisions 
under F follow the relation F \~u op over users U and operations op. Execution of an 
operation op under p follows the relation p\op\ JJ, p'\r\ over next stores p' and results 
r. Let K as be a secret key shared by A and S, and mac be a function over messages 
and keys that produces unforgeable message authentication codes (MACs) fl4l . We 
assume that MACs can be decoded to retrieve their messages. (Usually MACs are 
explicitly paired with their messages, so that the decoding is trivial.) 



(1) 


U - 


4 A 


op 


(2) 


A - 


-> U 


mac(op, Kas) if F op 


(2') 


A - 


-> u 


error otherwise 


(3) 


V - 


4 S 


K 


(4) 


S ~ 


-> V 


r if k — mac(op, Kas) 








andp[opH//[r] 


(4') 


S - 


* V 


error otherwise 



Here a user U requests A for access to an operation op, and A returns a capability 
for op only if F specifies that U may access op. Elsewhere, a user V requests S to 
execute an operation by sending a capability n, and S executes the operation only if k 
authorizes access to that operation. 

What does "safety" or "security" mean in this setting? A reasonable specification 
of correctness is the following trivial protocol, IS S , for ideal storage. Here principals 
include users U, V, W, . . . and a server D. The access policy F and the store p are 

1 By convention, we use superscripts s and d to denote "static" and "dynamic", and superscripts + and — 
to denote "extension" and "restriction". 
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both maintained by D; the access and execution relations remain as above. There is no 
cryptography. 

(i) V -> D : op 

(ii) D -> V : r if F h v op and p\op\ JJ-p'[r] 
(ii') £> — * : error otherwise 

Here a user V requests D to execute an operation op, and executes op only if F 
specifies that V may access op. This trivial protocol is correct "by definition"; so if 
NS S implements this protocol, it is correct as well. 

What notions of implementation correctness are appropriate here? A basic criterion 
is that of safety 0). 

Definition 1 (Safety). Under any context (adversary), the behaviors of a safe imple- 
mentation are included in the behaviors of the specification. 

In practice, a suitable notion of inclusion may need to be crafted to accommodate 
specific implementation behaviors by design (such as those due to messages (1), (2), 
and (2') in NS S ). Typically, those behaviors can be eliminated by a specific context 
(called a "wrapper"), and safety may be defined modulo that context as long as other, 
interesting behaviors are not eliminated. 

Still, safety only implies the preservation of certain trace properties. A more pow- 
erful criterion may be derived from the programming languages concept of semantics 
preservation, otherwise known as full abstraction |fT9l [T|. 

Definition 2 (Security). A secure implementation preserves behavioral equivalences 
of the specification. 

In this paper, we tie security to an appropriate may testing congruence ETl . We con- 
sider a protocol instance to include the file system and some code run by "honest" 
users, and assume that an arbitrary context colludes with the remaining "dishonest" 
users. From any NS S instance, we derive its IS S instance by an appropriate refinement 
map 10. If NS S securely implements IS S , then for all NS S instances Qi and Q 2 , Q\ 
and Q 2 are congruent if their IS S instances are congruent. 

Security implies safety for all practical purposes, so a safety counterexample usu- 
ally suffices to break security. For instance, we are in trouble if operations that cannot 
be executed in IS S can somehow be executed in NS S by manipulating capabilities. 
Suppose that F \fv op for all dishonest V. Then no such V can execute op in IS S . 
Now suppose that some such V requests execution of op in NS S . We know that op is 
executed only if V shows a capability k for op. Since k cannot be forged, it must be 
obtained from A by some honest U that satisfies F \~u op. Therefore: 

Rl Capabilities obtained by honest users must not be shared with dishonest users. 

(However U can still share k with honest users, and any execution request with k can 
then be reproduced in the specification as an execution request by U.) 

While (PjTJ prevents explicit leaking of capabilities, we in fact require that capabil- 
ities do not leak any information that is not available to IS S contexts. Information may 
also be leaked implicitly (by observable effects). Therefore: 
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R2 Capabilities obtained by honest users must not be examined or compared. 

Both (RfTJ and (Rf2]l may be enforced by typechecking the code run by honest users. 

Finally, we require that information is not leaked via capabilities obtained by dis- 
honest users. (Recall that such capabilities are already available to the adversary.) Un- 
fortunately, a capability for an operation op is provided only to those users who have 
access to op under F; in other words, A leaks information on F whenever it returns 
a capability! This leak breaks security. Why? Consider implementation instances Qi 
and Q2 with op as the only operation, whose execution returns error and may be ob- 
served only by honest users; suppose that a dishonest user has access to op in Q\ but 
not in Q2- Then Qi and Q2 can be distinguished by a context that requests a capabil- 
ity for op — a capability will be returned in Qi but not in Q2 — but their specification 
instances cannot be distinguished by any context. 

Why does this leak concern us? After all, we expect that executing an operation 
should eventually leak some information about access to that operation, since other- 
wise, having access to that operation is useless! However the leak here is premature; it 
allows a dishonest user to obtain information about its access to op in an undetectable 
way, without having to request execution of op. 

To prevent this leak, we must modify the protocol: 

R3 "Fake" capabilities for op must be returned to users who do not have access to op. 

The point is that it should not be possible to distinguish the fake capabilities from 
the real ones prematurely. Let Kas be another secret key shared by A and S. As a 
preliminary fix, let us modify the following message in NS S . 

(2') A -> U : mac{op,K A s) if F\/u op 

Unfortunately this modification is not enough, since the adversary can still compare 
capabilities that are obtained by different users for a particular operation op, to know 
if their accesses to op are the same under F. To prevent this leak: 

R4 Capabilities for different users must be different. 

For instance, a capability can mention the user whose access it authenticates. Making 
the meaning of a message explicit in its content is a good design principle for security 
0, and we use it on several occasions in this paper. Accordingly we modify the 
following messages in NS S . 



(2) 


A -» 


U : 


: mac(([7, op), Kas) if F op 


(2') 


A -» 


U : 


mac((U, op), Kas) otherwise 


(4) 


S 


V : 


: r if ac = mac((_, op),K A s) 



andp[opH/[r] 

(On receiving a capability re from V, S still does not care whether V is the user to 
which re is issued, even if that information can now be obtained from re.) 
The following result can then be proved (cf. 1 10|). 

Theorem 1. NS" securely implements IS S . 
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3 The case of dynamic access policies 



We now consider the more difficult problem of implementing dynamic access policies. 
Let F be dynamic; the following protocol, NS d , is obtained by adding administration 
messages to NS S . Execution of an administrative operation 9 under F follows the 
relation FjOJ JJ. F'fr} over next policies F' and results r. 

(5) W -> A : 9 

(6) A -> W : r if F \- w 9 and F{6} JJ i*"[r] 
(6') A — > W : error otherwise 

Here A executes 9 (perhaps modifying F) if F specifies that W controls 9. The fol- 
lowing protocol, IS , is obtained by adding similar messages to IS S . 

(iii) W -> D : 9 

(iv) D -> W : r if F \- w 6 and F\ff\ JJ. F'\r\ 
(iv') D — > : error otherwise 

Unfortunately iViS does not remain secure with respect to IS d . Consider the NS d 
pseudo-code below. Informally, acquire k means "obtain a capability k" and use n 
means "request execution with k"; chmod 8 means "request access modification 9"; 
and success means "detect successful use of a capability". Here k is a capability for 
an operation op and 9 modifies access to op. 

tl acquire k; chmod 9; use k; success 

t2 chmod 9; acquire k; use k; success 

Now (tl) and (t2) map to the same IS d pseudo-code chmod 9; exec op; success — 
informally, exec op means "request execution of op". Indeed, requesting execution 
with k in NS d amounts to requesting execution of op in IS d , so the refinement map 
must erase instances of acquire and replace instances of use with the appropriate 
instances of exec. However, suppose that initially no user has access to op, and 9 
specifies that all users may access op. Then (tl) and (t2) can be distinguished by 
testing the event success. In (tl) k does not authorize access to op, so success must 
be false; but in (t2) k may authorize access to op, so success may be true. 

Moreover, if revocation is possible, NS d does not even remain safe with respect to 
IS d \ Why? Let 9 specify that access to op is revoked for some user U, and revoked 
be the event that 9 is executed (thus modifying the access policy). In IS d , U cannot 
execute op after revoked. But in NS d , U can execute op after revoked by using a 
capability that it acquires before revoked. 

Safety in a special case One way of eliminating the counterexample above is to make 
the following assumption: 

Al Accesses cannot be dynamically revoked. 

We can then prove the following new result (see Section|6]l. 
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Theorem 2. NS d safely implements IS d assuming 

The key observation is that with (A[T|l, a user U cannot access op until it can always 
access op, so U gains no advantage by acquiring capabilities early. 

Safety in the general case Safety breaks with revocation. However, we can recover 
safety by introducing time. Let A and S share a logical clock (or counter) that measures 
time, and let the same clock appear in D. We have that: 

R5 Any capability that is produced at time Clk expires at time Clk + 1. 

R6 Any administrative operation requested at time Clk is executed at the next clock 
tick (to time Clk + 1), so that policies in NS d and IS d may change only at clock 
ticks (and not between). 

We call this arrangement a "midnight-shift scheme", since the underlying idea is the 
same as that of periodically shifting guards at a museum or a bank. Implementing 
this scheme is straightforward. For (R[5j, capabilities carry timestamps. For (F(6]l, 
administrative operations are executed on an "accumulator" 3 instead of F, and at 
every clock tick, F is updated to 3. Accordingly, we modify the following messages 
in NS d to obtain the protocol NS d+ . 



(2) 


A - 


■+ U : 


mac((£7, op, Clk), Kas) if F \~u op 


(2') 


A - 


■* U : 


mac ( (U, op , CI k) , Kas ) otherwise 


(4) 


S - 


■* V : 


r if k = mac((_, op, Clk), Kas) 








andpM^P'W 


(6) 


A - 


W : 


r ifFhw 0andS[0HS'[r] 



Likewise, we modify the following message in IS d to obtain the protocol IS d+ . 

(iv) D -> W : r if F h w 6 and 3[0] JJ. E'frj 

Now a capability that carries Clk as its timestamp certifies a particular access decision 
at the instant Clk: the meaning is made explicit in the content, which is good practice. 
However, recall that MACs can be decoded to retrieve their messages. In particular, 
one can tell the time in NS d+ by decoding capabilities. Clearly we require that: 

R7 If it is possible to tell the time in NS d+ , it must also be possible to do so in IS d+ . 

So we must make it possible to tell the time in IS d+ . (The alternative is to make it 
impossible to tell the time in NS d+ , by encrypting the timestamps carried by capabil- 
ities. Recall that the notion of "time" here is purely logical.) Accordingly we add the 
following messages to IS d+ . 

(v) U - D : () 

(vi) D -> U : Clk 

The following result can then be proved (cf. IfTTl ). 

2 Some implementation details, such as (1^5), are not required for safety. 
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Theorem 3. NS safely implements IS + . 

This result appears in [ 1 1 1. Unfortunately, the definition of safety in ifTTl is rather non- 
standard. Moreover, beyond this result, security is not considered in IfTTl . In the rest of 
this section, we analyze the difficulties that arise for security, and present new results. 

It turns out that there are several recipes to break security, and expiry of capabilities 
is a common ingredient. Clearly, using an expired capability has no counterpart in 
IS d+ . So: 

R8 Any use of an expired capability must block (without any observable effect). 

Indeed, security breaks without (R[8]l. Consider the NS d+ pseudo-code below. Infor- 
mally, stale means "detect any use of an expired capability". Here k is a capability 
for operation op. 

t3 acquire k; use n; stale 

Without (R[8]l, (t3) can be distinguished from a false event by testing the event stale. 
But consider implementation instances Q\ and Q2 with op as the only operation, whose 
execution has no observable effect on the store; let Qi run (t3) and Q2 run false. 
Since stale cannot be reproduced in the specification, it must map to false. So the 
specification instances of Qi and Q2 run exec op; false and false. These instances 
cannot be distinguished. 

Moreover, expiry of a capability yields the information that time has elapsed be- 
tween the acquisition and use of that capability. We may expect that leaking this infor- 
mation is harmless; after all, the elapse of time can be trivially detected by inspecting 
timestamps. Then why should we care about such a leak? If the adversary knows that 
the clock has ticked at least once, it also knows that any pending administrative oper- 
ations have been executed, possibly modifying the access policy. If this information is 
leaked in a way that cannot be reproduced in the specification, we are in trouble. Any 
such way allows the adversary to implicitly control the expiry of a capability before its 
use. (Explicit controls, such as comparison of timestamps, are not problematic, since 
they can be reproduced in the specification.) 

For instance, consider the NS d+ pseudo-code below. Here k and k' are capabilities 
for operations op and op' , and 8 modifies access to op. 

t4 acquire k'; 

chmod (9; acquire k; use k; success; 
use n'; success 

t5 chmod 8; acquire k; use k; success; 
acquire k'; use k'; success 

Both (t4) and (t5) map to the same IS d+ pseudo-code 

chmod 8: exec op; success; exec op'; success 

But suppose that initially no user has access to op and all users have access to op', and 
8 specifies that all users may access op. The intermediate success event is true only 
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if 6 is executed; therefore it "forces" time to elapse for progress. Now (t4) and (t5) can 
be distinguished by testing the final success event. In (t4) k' must be stale when used, 
so the event must be false; but in (t5) k' may be fresh when used, so the event may be 
true. Therefore, security breaks. 

Security in a special case One way of plugging such leaks is to consider that the 
elapse of time is altogether unobservable. (This prospect is not as shocking as it sounds, 
since here "time" is simply the value of a privately maintained counter.) 

We expect that executing an operation has some observable effect. Now if ini- 
tially a user does not have access to an operation, but that access can be dynamically 
granted, then the elapse of time can be detected by observing the effect of executing 
that operation. So we must assume that: 

A2 Accesses cannot be dynamically granted. 

On the other hand, we must allow accesses to be dynamically revoked, since otherwise 
the access policy becomes static. Now if initially a user has access to an operation, but 
that access can be dynamically revoked, then it is possible to detect the elapse of time 
if the failure to execute that operation is observable. So we must assume that: 

A3 Any unsuccessful use of a capability blocks (without any observable effect). 

Let us now try to adapt the counterexample above with (A[2]l and (A[3]). Suppose that 
initially all users have access to op and op', and 8 specifies that no user may access 
op. Consider the NS d+ pseudo-code below. Informally, failure means "detect un- 
successful use of a capability". 

t6 acquire k!\ 

chmod 8; acquire k; use k; failure; 
use k'; success 

t7 chmod 8; acquire n; use n; failure; 
acquire k'; use k'; success 

Both (t6) and (t7) map to the same IS d+ pseudo-code 

chmod 8; exec op; failure; exec op 1 ; success 

Fortunately, now (t6) and (t7) cannot be distinguished, since the intermediate failure 
event cannot be observed if true. (In contrast, recall that the intermediate success 
event in (t4) and (t5) forces a distinction between them.) 

Indeed, with (A[2]l and (A[3]l there remains no way to detect the elapse of time, 
except by comparing timestamps. To prevent the latter, we assume that: 

A4 Timestamps are encrypted. 
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Let Eas be a secret key shared by A and S. The encryption of a term M with Eas un- 
der a random coin m is written as {m, M}e as - We remove message (4') and modify 
the following messages in NS d+ to obtain the protocol NS d ~ . (Note that randomiza- 
tion takes care of (I©, so capabilities are not required to mention users here.) 

(2) A -> U : m a c((U,op,{m,Qk} EAS ),K A s) 

if F op 

(2') 4 - [/ : mac((C/, p,{m,Clk} £AS ),!? A 5) 

otherwise 

(4) S -> 1/: r if K = mac((., p,r),^As), 

T={. ) Clk} BAS ,andp[ pHp'[r] 

Accordingly, we remove the messages (iv'), (v), and (vi) from IS d+ to obtain the 
protocol IS d ~. We can then prove the following new result (see Section|6]): 

Theorem 4. NS d ~ securely implements IS d ~ assuming (A[3, (A|3), and (A@]l. 

The key observation is that with (A^K (ASJ, and (AHjl, time can stand still (so that 
capabilities never expire). 

Security in the general case More generally, we may consider plugging problem- 
atic leaks by static analysis. (Any such analysis must be incomplete because of the 
undecidability of the problem.) However, several complications arise in this case. 

• The adversary can control the elapse of time by interacting with honest users in 
subtle ways. Such interactions lead to counterexamples of the same flavor as the 
one with (t4) and (t5) above, but are difficult to prevent statically without severely 
restricting the code run by honest users. For instance, even if the suspicious-looking 
pseudo-code chmod 8; acquire n; use k; success in (t4) and (t5) is replaced by 
an innocuous pair of inputs on a public channel c, the adversary can still run the 
same code in parallel and serialize it by a pair of outputs on c (which serve as 
"begin/end" signals). 

• Even if we restrict the code run by honest users, such that every use of a capability 
can be serialized immediately after its acquisition, the adversary can still force time 
to elapse after a capability is sent to the file system and before it is examined. 
Unless we have a way to constrain this elapse of time, we are in trouble. 

To see how the adversary can break security by interacting with honest users, consider 
the NS d+ pseudo-code below. Here k is a capability for operation op, and 9 modifies 
access to op; further c() and w() denote input and output on public channels c and w. 

t8 acquire k; use n; c(); chmod 6; c(); success; w() 

t9 C ();c();W() 

Although use k immediately follows acquire k in (t8), the delay between use k and 
success can be detected by the adversary to force time to elapse between those events. 
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Suppose that initially no user has access to op or op' , 8 specifies that a honest user U 
may access op, and 9' specifies that all users may access op'. Consider the following 
context. Here k' q and k[ are capabilities for op' . 

c(); acquire k' ; use k' ; failure; 

chmod#'; acquire refuse success; c() 

This context forces time to elapse between a pair of outputs on c. The context can 
distinguish (t8) and (t9) by testing output on w. in (t8) k does not authorize ac- 
cess to op, so success is false and there is no output on w; on the other hand, in 
(t9) there is. Security breaks as a consequence. Consider implementation instances 
Qi and Q 2 with U as the only honest user and op and op' as the only operations, 
such that only U can detect execution of op and all users can detect execution of 
op'; let Qi run (t8) and Q2 run (t9). The specification instances of Qi and Q2 run 
exec op; c(); chmod 9; cQ; success; w() and c(); c(); w{), which cannot be distin- 
guished: the execution of op can always be delayed until 9 is executed, so that success 
is true and there is an output on w. Intuitively, an execution request in NS d+ commits 
to a time bound (specified by the timestamp of the capability used for the request) 
within which that request must be processed for progress; but operation requests in 
IS d+ make no such commitment. 

To solve this problem, we must assume that: 

A5 In IS d+ a time bound is specified for every operation request, so that the request 
is dropped if it is not processed within that time bound. 

Usual (unrestricted) requests now carry a time bound 00. Accordingly we modify the 
following messages in IS d+ . 

(i) V -> D : {op,T) 

(ii) D -> V : r ifClk<T, 

F^ v qp,andp[op]^//[rJ 

With (A|5]l, using an expired capability now has a counterpart in IS d+ . Informally, if 
a capability for an operation op is produced at time T in NS d+ , then any use of that 
capability in NS d+ maps to an execution request for op in IS d+ with time bound T. 
There remains no fundamental difference between NS d+ and IS d+ . We can then prove 
our main new result (see Section|6]i: 

Theorem 5 (Main theorem). NS d+ securely implements IS d+ assuming (A|5]lJl 

Fortunately, (AO seems to be a reasonable requirement, and we impose that require- 
ment implicitly in the sequel. 

Discussion Let us now revisit the principles developed in Sections [2] and [3] and dis- 
cuss some alternatives. 

First recall (F0, where we introduce fake capabilities to prevent premature leaks 
of information about the access policy F. It is reasonable to consider that we do not 

3 This result holds with or without (F(8). 
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care about such leaks, and wish to keep the original message (2') in NS S . But then we 
must allow those leaks in the specification. For instance, we can make F public. More 
practically, we can add messages to IS S that allow a user to know whether it has access 
to a particular operation. 

Next recall (R[5]) and (F(6]l, where we introduce the midnight-shift scheme. This 
scheme can be relaxed to allow different capabilities to expire after different intervals, 
so long as administrative operations that affect their correctness are not executed before 
those intervals elapse. Let delay be a function over users U, operations op, and clock 
values Clk that produces time intervals. We may have that: 

K[5] Any capability for U and op that is produced at time Clk expires at time Clk + 
delay([/, op, Clk). 

K(6] If an administrative operation affects the access decision for U and op and is re- 
quested in the interval Clk, . . . , Clk + delay(f/, op, Clk) — 1, it is executed at the 
clock tick to time Clk + delay (U, op, Clk). 

This scheme remains sound, since any capability for U and op that is produced at Clk 
and expires at Clk + delay(C7, op, Clk) certifies a correct access decision for U and op 
between Clk, . . . , Clk + delay(£/, op, Clk) — 1. 

Finally, the implementation details in Sections|2]and[3]are far from unique. Guided 
by the same underlying principles, we can design capabilities in various other ways. 
For instance, we may have an implementation that does not require Kas'- an y capa- 
bility is of the form mac ((([/, op, Clk), {m, L}e as ), Kas), where m is a fresh nonce 
and L is the predicate F htj op. Although this design involves more cryptography than 
the one in NS d+ , it reflects better practice: the access decision for U and op under F 
is explicit in the content of any capability that certifies that decision. What does this 
design buy us? Consider applications where the access decision is not a boolean, but a 
label, a decision tree, or some arbitrary data structure. The design in NS d+ requires a 
different signing key for each value of the access decision. Since the number of such 
keys may be infinite, verification of capabilities becomes very inefficient. The design 
above is appropriate for such applications, and we develop it further in Section|7] 



4 Definitions and proof techniques 

Let us now develop formal definitions and proof techniques for security and safety; 
these serve as background for Section [6] where we present formal models and proofs 
for security and safety of NS d+ with respect to IS d+ . 

Let ^ be a precongruence on processes and ~ be the associated congruence. A 
process P under a context ip is written as ip[P]. Contexts act as tests for behaviors, and 
P < Q means that any test that is passed by P is passed by Q — in other words, "P has 
no more behaviors than Q". 

We describe an implementation as a binary relation 1Z over processes, which re- 
lates specification instances to implementation instances. This relation conveniently 
generalizes a refinement map [4J. 
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Definition 3 (Full abstraction). An implementation 1Z is fully abstract if it satisfies: 
(Preservation) 

V(P, Q) G 11. V(P', Q')eK. P<P' ^ Q<Q' 
(Reflection) 

V(P, Q) G ft. V(P', Q') G ft. Q ^ Q' => P =< P' 

(Preservation) and (Reflection) are respectively soundness and completeness of 
the implementation under <. Security only requires soundness. 

Definition 4 (cf. Definition 2 [Security]). An implementation is secure if it satisfies 
(Preservation). 

Intuitively, a secure implementation does not introduce any interesting behaviors — if 
(P, Q) and (P', Q') are in a secure ft and P has no more behaviors than P', then Q 
has no more behaviors than Q' . A fully abstract implementation moreover does not 
eliminate any interesting behaviors. 

Any subset of a secure implementation is secure. Security implies preservation of 
~. Finally, testing itself is trivially secure since ^ is closed under any context. 

Proposition 6. Let ip be any context. Then {(P, <^[P]) | P G W} is secure for any set 
of processes W. 

On the other hand, a context may eliminate some interesting behaviors by acting as a 
test for those behaviors. A fully abstract context does not; it merely translates behav- 
iors. 

Definition 5 (Fully abstract context). A context <p is fully abstract for a set of processes 
W if{(P, <p[P]) | P G W} is fully abstract. 

A fully abstract context can be used as a wrapper to account for any benign differences 
between the implementation and the specification. An implementation is safe if it does 
not introduce any behaviors modulo such a wrapper. 

Definition 6 (cf. Definition 1 [Safety]). An implementation ft is safe if there exists a 
fully abstract context <f>for the set of specification instances such that 1Z satisfies: 

(Inclusion) 

V(P, Q) G K. Q r< tf>[P] 

Let us see why <fi must be fully abstract in the definition. Suppose that it is not. Then 
for some P and P' we have 4>[P] ^ 'PIP'] an d P Z: P' ■ Intuitively, <f> "covers up" 
the behaviors of P that are not included in the behaviors of P'. Unfortunately, those 
behaviors may be unsafe. For instance, let P' be a pi calculus process |20| that does not 
contain public channels, and {P'} be the set of specification instances — we consider 
any output on a public channel to be unsafe. Let c be a public channel; let P = c(); P' 
and 4> = • | ! c(). Then P ^ P' and 4>[P] di <j>[P'], as required. But clearly P is 
unsafe by our assumptions; yet P ^ 0[P'], so that by definition {(P', P)} is safe! The 
definition therefore becomes meaningless. 
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We now present some proof techniques. A direct proof of security requires map- 
pings between subsets of X. Those mappings may be difficult to define and manipulate. 
Instead a security proof may be built modularly by showing simulations, as in a safety 
proof. Such a proof requires simpler mappings between processes. 

Proposition 7 (Proof of security). Let 4> and tp be contexts such that for all [P, Q) £ 1Z, 

Q ^ 4>[P], P d lp[Q], and 4>[ip[Q]\ d Q- Then K is secure. 

Proof. Suppose that (P, Q) E K, P < P', and (P', Q') £ K. Then Q < <j>[P] < 
0[P'] < <Pk<p[Q>]} < Qi. □ 

Intuitively, 1Z is secure if 1Z and TlT 1 both satisfy (INCLUSION), and the witnessing 
contexts "cancel" each other. A simple technique for proving full abstraction for con- 
texts follows as a corollary. 

Corollary 8 (Proof of full abstraction for contexts). Let there be a context ip~ 1 such 
that for all P £ W, <f>~ 1 [tp[P\\ ~ P. Then tp is a fully abstract context for W. 

Proof. Take <f> = tp~ 1 and %j} = (p in the proposition above to show that {(ip[P],P) | P £ 
W} is secure. The converse follows by Proposition[6] □ 

Theory for the applied pi calculus Let a, b, . . . range over names, u,v, . . . over 
names and variables, M, N, . . . over terms, and A,B,... over extended processes. 

Semantic relations include the binary relations =, — >, and — ► over extended processes 
(structural equivalence, reduction, and labeled transition); here labels I are of the form 

a(M) or (yu) a(v) (where a £u and u Qv). Both — > and — > are closed under = and 
— ► is closed under arbitrary evaluation contexts. 

We recall some theory on may testing for applied pi calculus programs. 

Definition 7 (Barb). A barb |„ is a predicate that tests possible output on a; we write 

A l a if A ^ > ^ B for some B, v, and u. A weak barb J|„ tests possible eventual 
output on a, i.e., 4|a — la- 
Definition 8 (Frame). Lef A be closed. Then we have A = (va) (a \ P) for some a, a, 
and P such that f v(rng(tr)) U f v(P) = 0; define f rame(yl) = {va) a. 

Definition 9 (Static equivalence). Let A and B be closed. Then A is statically equiv- 
alent to B, written A « s B, if there exists a, a, and a' such that f rame(yl) = (ya) a, 
frame(B) = [ya) a', dom((j) = dom(cr / ), and for all M and N, 

{a} n (f n(M) U fn(AT)) = => Mtr = iVcr ^ Mcr' = Na' 

Proposition 9. AK s fi i/anJ only if frame [A) ~ f rame(P). 

Proof. By induction on the structure of closing evaluation contexts. □ 
We can prove < by showing a simulation relation that approximates 
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Definition 10 (Simulation preorder). Let =4 be the largest relation S such that for all 
A and B, (A, B) G S implies 

• A^ S B 

• MA'. A^ A' => 3B'. B — >* B' A (A', B') G S 

• VA',a. A-U A' => 3B'. B >* B' A (A',B') G S 
Proposition 10 (Proof of testing precongruence). =<! C ^. 

5 Models and proofs for static access policies 

We now present implementation and specification models and security proofs for static 
access policies. Models and proofs for dynamic access policies follow essentially the 
same routine, and are presented in the next section. 

5.1 Preliminaries 

We fix an equational theory £ with the following properties. 

• E includes a theory of natural numbers with symbols (zero), _ + 1 (successor), 
and _ < _ (less than or equal to). 

• E includes a theory of finite tuples with symbols (_, _) (indexed concatenate) and 
_ . _ (indexed project). 

• E contains exactly one equation that involves the symbol mac, which is 

msg(mac(a;, y)) = x 

Clients are identified by natural numbers; we fix a finite subset I of N and consider 
any user not identified in 2 to be dishonest. 

File-system code and other processes are conveniently modeled by parameterized 
process expressions, whose semantics are defined (recursively) by extending the usual 

semantic relations =, — and — ►, 

5.2 Models 

Figures Q] and [2] show applied pi calculus models for the file systems under study. We 
ignore the rules in the inner boxes in these figures (labeled (Dummy...)) in a first 
reading. 

FigureQ]models a traditional file system (with local access control). The file system 
is parameterized by an access policy F, a store p, and a renaming 77 of its default 
interface. That interface includes a channel /3£ for every k G N; intuitively, a user 
identified by k may send operation requests on this channel. 

Processes Req fc (F, op, n) and E0k(M, op, n) denote internal states. In the equa- 
tional theory auth(i^, k, op) — ok means that user k may access op under F, and 
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(Op Req) (Op Ok) 

k G N perm(F, k, op) = L 



TFS(F,p)" = V (p k )(op,x);Req k (F,op,xr | TFS(F,p)" Req fc (F, op, M) -> EOk(L, op, M) 
(Op Exec) 

exec(L, op, p) — (TV, p) 



E0k(L, op, M) | TFs(F,p)" -> M(N) \ TFs(F,p') r ' 



(Dummy Auth Req) 

3 G N\T 



Tnas'' = ?7(aj)(op,a:);a;(mac((j, op),K?)) | TnIs* 7 

(Dummy Op Req) 

(Dummy Exec Req) k = macfmsgf/t), if?) 

j € N\T msg(/t) = 0', op) j G N\J 



Ti AS " = ijCA-)(«, x); DReq( K , i)" | tSL" DReq(fi, M )" - 7?(/3°)(op, M> 



Figure 1 : A traditional file system with local access control 



(Auth Req) 


(Auth Cap) 

fc G N cert(F,fc, op) = k 


NAFS(F,p)" E 


5 ?7(a fe )(op,x);CReq fc (F, op, a;) | NAFS(F,p)" CReq fc (F, op,M) M(«) 


(Exec Req) 


(Op Ok) 

verif(/t) = L L G {true, false} 
fc G N msg(«:) = {_, op) 


NAFS(F,p)" = 


r)(/3 k )(K,x); Req(«;,:r) | NAFS(F, p) v Req(«,M) -> EOk(L, op, M) 
(Op Exec) 

exec(L, op,p) = (iV,p') 
E0k(L, op, M) | nafs(F, p)" -> M(N) | nafs(F, p')" 


(Dummy Op Req) 

j e N\T 

^ = r,(f3°)(op,xy,DRe qj (op,xy j T^ 8 " 
(Dummy Auth & Exec Req) 

DReq^op.M)" = (i/c) r](aj)(op, c); c(k); r)((3j)(K, M) 



Figure 2: A network- attached file system with distributed access control 
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exec(L, op, p) = (N, p') means that the execution of op on store p under decision L 
returns N and store p'. Decisions are derived by perm(_, _, _) as follows. 

L = true if auth(F, k, op) = ok, = false otherwise 
perm(_F, k, op) = L 

A traditional storage system may be described as 

( Vi& ft)iC\ws(F,p)) 

Here C is code run by honest users; the file-system exports the default interface (im- 
plicitly renamed by "identity"), and channels associated with honest users are hidden 
from the context. The context may be arbitrary and is left implicit; in particular, chan- 
nels associated with dishonest users are available to the context. 

Figure |2] models a network-attached file system (with distributed access control). 
As above, the file system is parameterized by an access policy F, a store p, and a 
renaming r\ of its default interface. That interface includes channels at and (3k for 
every k e N; intuitively, a user identified by k may send authorization requests on ctk 
and execution requests on (3k ■ 

Processes CReq k (F, op,c), Req(/«, n), and EOk(Af, op,n) denote internal states. 
In the equational theory auth(F, k, op) — ok and exec(i, op, p) — (N, p') have the 
same meanings as above. Capabilities and decisions are derived by cert(_, _, _) and 
verif (_) as follows. 

a = Kmd if auth(F, k, op) = ok, = K' M otherwise 
cert(F, k, op) = mac((fc, op), a) 

L = true if k = mac(msg(K), Kmd), — false if k — mac(msg(K), K' M ) 

verif(n) = L 
A network-attached storage system may be described as 

{v ieI oti(3i){C I {vKmdK' m ) nafs(F,p)) 

As above, C is code run by honest users; the file-system exports the default interface 
and hides the keys that authenticate capabilities. Channels associated with honest users 
are hidden from the context. The context may be arbitrary and is left implicit; in 
particular, channels associated with dishonest users are available to the context. 

5.3 Proofs of security 

We prove that the implementation is secure, safe, and fully abstract with respect to the 
specification. We begin by outlining the proofs, and then present details. 

5.3.1 Outline 

Let F, p, and C range over access policies, stores, and code for honest users that 
are "wellformed" in the implementation. Let |~_] abstract such F, p, and C in the 
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fn(M) n (A U {a 3 ,l3 3 \ j G N\J}) = 


\P]r = Q rDfeft |j6N\2} 


\M~\ = M 




dom(r) D A n<f_ dom(r) 
r0] r = [(vn)Plr = M fP] r 


[P|Qlr= TPlr | TOlr l^r = l^lr 


f nv(u, -r) n dom(r) = 


fnv(u, M) n dom(r) = 


rw(s);Plr = w(5); \P~\v 


r«{M>;Pl =^{M);rPl 


f nv(M, N) n dom(r) = 


[if M = N then P else Q] r = if M = N then |P] r else [Q] r 


i e l 


{i,i'}CI T(x) = Cert(i', op) 


fnv(c, :c) n dom(r) = c ^ f n(P) 


f nv(op, M) D dom(r) = 


[(i/c)a7(op,c);c(2;);Plr = rP~|r> : cert(i, op ) 


(fr(x,M);P] r =W{op,M); \P] r 


Figure 3: Abstraction function 


specification. We define 




n= u {(^ eI/ 3°)(rciiTFs(rpi,M)) 


(^ eX aift)(C | (^md^m)nafs(F, P ))} 


F,p,C 





We prove that 7?. is secure by showing contexts <ft and iji such that: 
Lemma 11. For any F, p, and C, 

1. (y l eia l (3. l )(C\{vK MD K' M )^s{F,p)) < (f)[(v ieI /3°)(\C] | TFS ( fi* 1 ") , |p]))] 

2. (^ e xA ? )(rCl |TFS([F1,M)) r< %l>[(yi£x a iPi){C \ (v K md K ' m )n AF S ( F, p))] 

3. 4>[il>[(yiei<*i0i)(C \ (vK md K' m )nafs(F, P ))]\ 

1 {VieiOiPi){C | (i/ifMD^) NAFS(P,p)) 

Proposition |7] then applies. Moreover we show: 
Lemma 12. Por any P, /?, ana" C, 

m(^pmc]\rM\Fi\p\))}] ± feA°)(rciiTF S (rpi,rpi)) 

Now 7^ _1 is secure by Proposition [7] Thus 7?. is proved fully abstract. Moreover 
Lemmas [TT] 1-2 already imply the converse of Lemma [T2l so is a fully abstract 
context by Corollary [8](taking _1 = tp). Thus 1Z is proved safe. 

We now revisit Figures Q] and [2] and focus on the rules in the inner boxes. Those 
rules define processes T^as an( ^ 1"ts" S - Intuitively, these processes translate public 
requests from NAS S to TS S and from PS" 5 to NAS S . Let a T s and a NA s include the 
public interfaces of TS S and iV.4,5" 5 . We define 

4> = (^a TS ) (• I Tnas) 
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fa(/t, M) n A = fceN fn(op,M) n.A = 

Req( K ,M) S( F DReq(«:, M) V2 Req(cert(F, k, op),M) S[ F Req k (F, op, M) 

fn(L, op, M) n A = j€ N\Z f n(L, op, M) n A = 

EOk(L, op, M) S[ F EOk(L, op, M) CReq^F, op, M) S'f M(mac((j, op), K ? )> 

(File systems) 

Vr <E £. P r S' F Q r f n(p) n A = 

nafs(f,p) |rr, s£ p. s[ tfs(f,p)" 2 |n rec Q r 

(Honest users) 

Va;. x £ dom(o-) =>• 3i £ T, op. T(x) = Cert(i, op) A cr(a;) = cert(F, i, op) 

Co «S 2 r ' F \C]r 

iel P 5 2 r ' F g T(x) = Cert(i, op) j£l P 5" Q r(x) = Cert(i, op) 
(i/c)(c(x);P | CReq t (F, op, c)) S F Q {vc)(c{x);P \ c(cert(F,i, op)}) S F Q 

(Trusted code) 

P Sf Q P' Sz ' F Q' Vr 6 £. P r S[ Q r 
{^exa^^P | P' | n reC P r ) S' F (i/ iG i/3?)(0 I <?' I n Pe£ Q r ) 
(System code) 

P <S' F Q Vx,iV. (3a. a = { N / x } | a') N : F Export 

{vn){uK MD K' M ){o | P) 5 (^(i/J^M*) | (^ eN \i/3° ? )(Q I T^ls" 2 )) 



Figure 4: Simulation relation for LemmafTTll (_ =<; 0[_]) 

The abstraction function [~_] is shown in Figure [3] Here ^4 contains special names 
whose uses in well-formed code are either disciplined or forbidden. 

A={a it (3i \ i£l}U {a 0V f3 3V f3°, \ j G N\X} U {K MD , K' M , K ? } 

The names in {a J? , /3j- ? , /3° ? | j 6 N\X}U {if?} are invented to simplify proofs below. 

5.3.2 Simulation relations 

Figures [4] [5] and|6]show simulation relations for LemmafTTll -3. All these relations 
are closed under =. Here r/i and r/2 rename the public interfaces of NAS S and TS S 
and 773 renames the private authentication keys Kmc an d K' M . 

r]i = [atj 1 * ay 7 , /3j i-> I j G N\J] 

^2 = - /?° ? I J G N\2] 

% = [a i-> A'? I a G {K M d, K' m }] 

These renamings map to names in A that do not occur in wellformed code (see Fig- 
ure [3}. In particular, the purpose of r\\ and 772 is to rename some public channels to 
fresh ones that can be hidden by restriction in tp and 4>. (A similar purpose is served by 
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fcGN fn(op,M) flA = fn(L, op,M) C\A = 

Req k (F,op,M) T[ Req(cert(F, k, op), M) EOk(L, op, M) T( EOk(L, op, M) 

(File systems) 

Vr e C. P r T{ Q r f n(p) n A = 

TFS(F,p)\Il re £P r Tf NAFS(F,p) m \n re£ Qr 

(Honest users) 

~ix. x £ dom(cr) =>• 3i £ X, op. = Cert(i, op) A <j(x) — cert(F, i, op) 

C i T/ (Vt 

(System code) 

Pi 7f Qj P 2 T 2 F Q 2 
P = (^ gJ /3°)(A I ft) Q = (i/i 6 ia</3i)(^MD^)(Qi I ga) 
| P) T (™)(a | (^ 6N \xa J? A ? )(g | T^ 3 " 1 )) 



Figure 5: Simulation relation for Lemma[TTl2 (_ =^ ip[J[) 

quantification in logic.) Hiding those names strengthens Lemmas [TT1 1-2 while not af- 
fecting their proofs; but more importantly, the restrictions are required to prove Lemma 
[TT13. Further the purpose of rj 3 is to abstract terms that may be available to contexts. 
Such terms must be of type Export; intuitively, Kmd an d K' M may appear only as 
authentication keys in capabilities issued to dishonest users. 

N = N'a {K MD , K' m , K 7 } n fn(N') = 
\/L 6 rng(o-). 3j € N\I, op. L = cert(F, j, op) A op :f Export 

N : p Export 

We show that term abstraction preserves equivalence in the equational theory. 

Lemma 13. Suppose that M : p Export and N : p Export. Then M = N iff 
m(M)=ri 3 (N). 

This lemma is required to show static equivalence in proofs of soundness for the 
relations S, T, and U in Figures|U|5j and|6l which in turn lead to LemmaUT] We prove 
that those relations are included in the simulation preorder. 

Lemma 14. 5C^,T C =<;, andU C =<;. 

Intuitively, by S a network-attached storage system may be simulated by a tradi- 
tional storage system by forwarding public requests directed at NAFS to a hidden TFS 
interface (via (f>). Symmetrically, by T a traditional storage system may be simulated 
by a network-attached storage system by forwarding public requests directed at TFS 
to a hidden NAFS interface (via ip). Finally, by U a network-attached storage system 
may simulate another network-attached storage system by filtering requests directed at 
NAFS through a hidden TFS interface before forwarding them to a hidden NAFS inter- 
face (via <j)[ijj]). This rather mysterious detour forces a fresh capability to be acquired 
for every execution request. 
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fn(/t,M)n.A = jGN\J fn{op,M)nA = 

DReq(n, M) m U[ F Req( K ,M) pf~ f (op,M) U' F Req(cert(F, j, op), M) 

j G N\J fn(op, A/) nA = 
DRe qj (op, M)" 1 ®" 2 «{ F Req(cert(F, j, op),M) 
j G N\J fn(op,Af) n.4 = 
(vc)(c(x);]3^{x,M) j CReq^F, op,c)) W( F Req(cert(F, j, op),M) 

j G N\J fn(op, M) n .4 = 
(vc)(c{x);~j3f 1 {x, M) | c(cert(F, j, op)}) W{ F Req(cert(F, j, op), M) 
j G N\J fn( op, A'/) nA = 
ft~(cert{F,j,op),M) U[ F Req(cert(F, j, op),M) 

jGN\J fn(op, A/) n.4 = 
Req(cert(F, j, op), M) W( F Req(cert(F, j, op), M) 
in(L,op,M)nA = jen\I fv.(op,M)ClA= 

EOk(L, op, M) U'f EOk(L, op, M) M(mac((j, op), K ? )) U[ F CReq^F, op, M) 

(File systems) 

Vr G £. P r U[ F Q r fn(p) n ^ = 

TnIs" 2 I tTC 8 " 1 ®" 2 | NAFS(F,p)" 1 | n re£ P r Wf NAFS(F, /9 ) | Il re£ Q r 

(Honest users) 

[C]r = C° Va;. a; G dom(o-) =>■ 3i G I, op. T(x) = Cert(i, op) A a(a;) = cert(F, i, op) 

Co U\' F Co 
i el P W 2 r,F Q T(x) = Cert(i, op) 
(^c)(c(s);P | CReq,(F, op, c)) W 3 F (vc)(c(x); Q | CReq^F, op, c)) 
(Trusted code) 

F Wf Q P' U F Q' Vr G C. P r U F Q r 
{u^iaiPi){vKMDK' M ){P | F' | LL, 6£ p.) U ,F (^^AKQ | Q' | n re£ Q r ) 

(System code) 

F W' F Q Va;,JV. (3a'. a = {^j | a') =*> N : F Export 
(vn)(vK?) (773(0-) I (^ 6 N\i/3j ? a J? /3i ? ) F) W {vn){vK M DK' M )(o \ Q) 

Figure 6: Simulation relation for LemmafTTl3 -) 
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jeN\l fn(op,r,M)nA 
j G N\J fn( op, M) n A = N = mac((j, op),Kv) 



DRe qj (op,M) Vf Re qj (op,M) (Vc) (<:(«);#,•,(«, M) ] c(AT» V( F Req^op.M) 

j'eN\l ±n(o P ,M) nA = j e N\J fn(op, A/) n .4 = 

N — msic({j, op) , K?) L = perm(P, j, op) JV = mac((j, op), if?) L = perm(P, j, op) 
J^{N,M) V'f EOk(L, op, M) DReq(iV, A/)" 1 ®" 2 V( F EOk(L, op, Af) 

j G N\J fn(op, Af) 11 A = L = perm(P, j, op) 
~Pf 7 (op,M) VP EOk(L, op, M) 

fn(op,M) n.4 = tn{adm, M) C\ A = 



EOk(L, op, M) Vf EOk(L, op, M) AReq fc (adm, M) V[ F AReq k (adm, M) 



(FILE SYSTEMS) 



Vr G £. P r V[ F Q r f n(p) D .4 = 



tST" 1 1 t£I s ™ I tfs(p,p)" 2 1 n re£ p. vf< Llk tfs(f,p) 1 n re£ g r 

(SYSTEM CODE) 

D1|F 1 D ' v 2 



P Vf Q P' V 2 F ' '' 



(z/n)(o- ] (yjetf\i/3j 7 oij ? Pj 7 ) P") V (im)(o- [ Q") 
Figure 7: Simulation relation for Lemma[12]('i/>[0[_]] =<! _) 

By definition of |~_] and alphaconversion to default public interfaces, we have for 
any F, p, and C: 

1. {v i&I a i (3 i ){C\{vK M DK> M )KAYS{F,p)) 4 0[(^ei/3°)([C] | tfs(|~F], \p\))\ 

2. (v iex 0i)(\C]\TP$(\F],\p\)) 4 i } [{v ieI a i (3 i ){C\{vK MD K' M )^s{F,p))} 

3. <j>[^[{v ie iaA){C I (uKmdK'm) nafs(P»)]] 

^ {u ie iOiPi){C I (uK M dK' m ) nafs(F,p)) 

LemmafTTIfollows by PropositionfTUl Thus 7Z is secure. 

Further, Figure [7] shows a simulation relation for Lemma Q~2] We prove that the 
relation V is included in the simulation preorder. 

Lemma 15. VC^. 

By definition of |~_] and alphaconversion to default public interfaces, we have for 
any F, p, and C: 

mWieipmc] iTFs(mM))]] * (MierAxrci 1 TFscrin, rpi» 

Lemma[T2]follows by Proposition[lO] Thus 1Z is safe and fully abstract. 
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6 Models and proofs for dynamic access policies 



Next we present models and proofs for dynamic access policies, following the routine 
of Section|5] 

6.1 Models 

The models extend those in Section [5] and are shown in Figures [8] and [9] (As usual, 
we ignore the rules in the inner boxes in a first reading.) Interfaces are extended with 
channels 5k and 61 for every k, on which users identified by k send administration 
requests in the implementation and the specification. 

In the equational theory auth(i^, k, op) = ok and exec(L, op, p) — (N, p') have 
the same meanings as in Section|5] Capabilities are derived by cert(_, _, _) as fol- 
lows. 

a = Kmd if auth(F, k, op) = ok, = K' M otherwise 
cert(F, k, op, Clk) = mac((fc, op, Clk), a) 

Recall that administrative operations scheduled at time Clk are executed at the next 
clock tick (to Clk + 1). In the equational theory push(L, adm,S, Clk) = (N, S') 
means that an administrative operation adm pushed on schedule 5 under decision L at 
Clk returns N and the schedule EE'; and sync(F, EE, Clk) = F 1 means that an access 
policy F synchronized under schedule EE at Clk returns the access policy F'. 
A traditional storage system may be described as 

(v ieI a°f3°5°)(C\TFS(F,0,O,p)) 

where C is code run by honest users, F is an access policy and p is a store; initially the 
schedule is empty and the time is 0. 

Similarly a network-attached storage system may be described as 

(y iexai l3iSt)(C \ [vK MD K' M ] nafs(F, 0, 0, p)) 

As usual, let F, p, and C range over access policies, stores, and code for honest 
users that are "wellformed" in the implementation, and let [~_] abstract such F, p, and 
C in the specification. We define 

ft = Uf, p ,c{ (yteraSfiSZWC] | tfs( ^1,0,0, M)) 

(viezati0i6i)(C \ {vK MD K' M ) nafs(F, 0, 0, p)) } 

Figure [TOlshows the abstraction function |~_~|. Here 

A= {a jv p Jv 8 Jv c$ v % v q ? j e N\I}U{K M d, K' m , K^u^, (3 l ,8 l \ iel} 

6.2 Examples of security 

At this point we revisit the "counterexamples" in Section[3] By modeling them formally 
in this setting, we show that those counterexamples are eliminated. 
Recall (tl) and (t2). 
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(Clk Req) 

ken 



tfs(F, E, Clk, pf = r){a° k ){x); TReq(z) \ tfs(F, E, Clk, pf 
(Time) 



k g N 



TReq(M) | TFS(F, S, Clk, pf -> M{Clk> | TFS(F, E, Clk, pf 
(Adm Req) 



fc e N 



TFS(_F, E, Clk, p)" = r)(6l)(adm, x); AReq fc (adm, x) | TFS(F, E, Clk, p) v 
(Adm Ok) 

perm(F, fc, adm) — L push(L, adm, E, Clk) = (N, E') 
AReq k (adm,n) | tfs(F, S, Clk, p)" — > n(JV) | tfs(F, Clk, p)" 
(Op Req) 

fc € N 

TFS(F,E,Clk,p)" = ?? (^)(op,r,x);Req fc ( p,r, ; r) | TFS(F, S, Clk, p)" 
(Op Ok) 

perm(_F, fc, op) = L Clk < r 
Req fc (op,r,M) | 7Fs(F,E,C\k, pf EOk(L, op, M) | tfs(F, S, Clk, pf 
(Op Exec) 

exec(L, op,p) = (Af,p') 

EOk(L, op, M) | tfs(F, S, Clk, pf -> ~M{N) | tfs(F, S, Clk, p')" 
(Tick) 

sync(F, S, Clk) = F' 
tfs(F, S, Clk, pf tfs(F', S, Clk + 1, pf 

(Dummy Adm Req) 

3 G N\T 



Tnas = v(Sj)(op,x);ri(8°){op,x) \ Tnas 
(Dummy Auth Req) 

i e N\T 



Tnas 11 = ^(aj)(op,a;); (i/m) ?7(a?)(m);m(Clk); z(mac(0', op, Clk), K?) | Tnas'' 
(Dummy Exec Req) 

J 6 N\T 



t^ s AS v =7,(13,)^, x);DReq(K,xf | Tnas" 
(Dummy Op Req) 

k — mac(msg(K), Kv) msg(fc) = (_, op, Clk) 



DReq(fi, Mf — 7?(/3°)(op, Clk, M) 



Figure 8: A traditional file system with local access control 
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(Adm Req) 

ken 



nafs(F, S, Clk, p) v = r)(5k){adm, x);AReq k (adm, x) \ nafs(F, E, Clk, p) v 
(Adm Ok) 

perm(_F, k, adm) = L push(L, adm, 3, Clk) = (N, 3') 
AReq k (adm,M) | NAFS(F, H, Clk, pf -^M(N) | NAFS(F, H', Clk, p) v 
(Auth Req) 

ken 

NAFS(F, S, C\k,p) v = r](a k )(op,x)- CReq k (op,x) | NAFS(F, S, Clk, p) 77 
(Auth Cap) 

cert(F, k, op, Clk) = k 
CReq fc (op, M) | nafs(F, H, Clk, p) n M{k) | nafs(F, H, Clk, p) v 
(Exec Req) 

k € N 

NAFS(F, H, Clk, p) 11 = rj(f3 k )(K, x); Req(n, x) \ NAFS(F, 3, Clk, p) v 
(Op Ok) 

verif(jv) — L L 6 {true, false} msg(fc) = {_, op, Clk) 
Req(/t, M) | nafs(F, H, Clk, pf -> EOk(L, op, M) | nafs(F, H, Clk, p)" 
(Op Exec) 

exec(L, op, p) = (iV, p) 
EOk(L, op, M) | nafs(F, H, Clk, p)" -> W(N) | nafs(F, H, Clk, p'f 
(Tick) 

sync(F, 3, Clk) = F' 
nafs(F, H, Clk, pf ^ nafs(F', H, Clk + 1, p)^ 

(Dummy Clk Req) 

j e N\T 



Tts =??(ai)(a;');(^c)r?(a ; ,){x,c);c(y);a;{msg(y).3) | Tts 
(Dummy Adm Req) 

3 6 N\J 

T^ S,? = 77(^)(op,x);^)(op,x) | t^ 8 " 

(Dummy Op Req) 

j e N\J 

Tts S " = v(Pj)(op,r,x); {vc) r){a.j){op,c);c{n); [msg(«;).3 < r] r)(P d )(K,x) | Tts 8 " 



Figure 9: A network- attached file system with distributed access control 
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f n(M) n (A U {a 3 , ft , jj | j € N\J» = ^1r = Q rgKftj^£N\I} 
|~M] = M \P] = Q 

iel fnv(adm,M) n dom(r) = 
["5~<adm,M);P~|r = S°(adm,M); \P]r 
i e 1 f nv(c, x) n dom(r) = c £ f n(P) 
|"(i/c) al(op,c);c(a;);Plr = (i/c) o°(c);c(x); rPlr>:Cert(i,op) 
{i,i'} CI F{x) = Cert(i', op) fnv(op, M) n dom(r) = 
|^foM);Plr = pT<op,z,M>; [Plr 

Figure 10: Abstraction function 

tl acquire k; chmod £; use k; success k 
tl chmod £; acquire k; use k; success k 
The following fragments of NAS d code formalize these traces. 

11 {vc) cti(op, c); c(/t); (i/m) o"i(£, to); m{z); {vn) n); n(x); [success(x)] w() 

12 {vm) 6i(C, m); m{z); {vc) al(op, c);c{k); {vn) n); n(x); [success(x)] wQ 
This code is abstracted to the following fragments of TS d code. 

51 {vc) a°(c); c(r); (i/m) <5°(C, m);m{z); {vn) (3° {op, t, n);n{x); [success(x)] wQ 

52 (Vm) <5°(C, m);m{z); {vc) a°{c);c{r); {vn) (3° {op,T,n);n{x)\ [success(cc)] wQ 

Now whenever (II) and (12) can be distinguished, so can (SI) and (S2). Indeed the 
time bound r is the same as the timestamp in k; so (in particular) the operation request 
in (SI) is dropped whenever the execution request in (Tl) is dropped. 

A similar argument counters the "dangerous" example with (t4) and (t5): 

t4 acquire k; chmod acquire k'; use k'; success «/; use k; success k 

t5 chmod acquire k'; use k'; success «/; acquire k; use k; success k 

Finally, recall (t8) and (t9). 

t8 acquire n; use k; c(); chmod £; c(); success k; w{) 

t9 cQ;cQ;w() 

The following fragment of NAS code formalizes (t8). 

13 {vm)ai{op,rn);m{K)-,{vn)(3i{K,n)\ 

c(); {vm) Si{(, m); m{z); c(); n{x); [success(x)] wQ 
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This code is abstracted to the following fragment of TS d code. 

S3 (vm) a°(m);m(r); {vri) (3° (op,T,n); 

cQ; {vm) S°((, m);m(z);c(); n(x); [success(x)] W() 

A NAS d context distinguishes (13) and (t9): 

c(); aj(op', to ); to (k ); (3j{n' , no); n a (x); [f ailure(x)] 

8j((,p); aj(op', mi);mi(K[y,Pj(Ki,ni); ni(x); [success(x)] c() 

But likewise a TS d context distinguishes (S3) and (t9): 
c(); aj(m );m (To); (3° (op 1 , r , n );n (x); [f ailure(x)] 

^(C,p);a° J (mi);m 1 (T[);P°(op',T[,n 1 );n 1 (x); [success(i)] c() 

6.3 Proofs of security 

We show that 1Z is secure, safe, and fully abstract. Recall the contexts cf> and ip defined 
in Section|5] The processes t^s S an d ^nas are redefined in the inner boxes in Figures 
[S]and[9] In particular, the rule (Dummy Op Req) in Figure|9]translates time-bounded 
operation requests by TS d contexts. 

Simulation relations for security are shown in Figures QT] |T2] andQj] and a simu- 
lation relation for safety and full abstraction is shown in Figure [14] Here 

Vi ~ i a j ^ a 3vPi ^ &'?> 5 i ^ S J? I 3 e N\2] 
m 4 [a°^a° ? ,/3°^/3° ? ,^^^ ? |jeN\Z] 

A binary relation _ _, _ ("leads-to") is defined over the product of access policies 
and clocks. Access policies may change at clock ticks (but not between). 

F', Clk' ~> F, Clk = (Clk' < Clk) V (Clk' = Clk A F' = F) 

As usual, any term that may be available to contexts must be of type Export. 

N = N'cr {Kmd, K' m , K?} n fn(N') = 
VL € rng(cr). 3j E N\J, op, Clk'. op :^,F,cik Export A (J^(Clk'), Clk' ~» F, Clk) 

A L = cert(J"(Clk'),j, op, Clk') 

N 

^.-F.Cik Export 

We prove that the relations S, T, and U in Figures [TT] [12J and [13] are included in 
the simulation preorder. Some interesting points in those proofs are listed below. 

• In Section [5] when an operation request is sent in TS S we send an appropriate 
authorization request in NAS S , obtain a capability, and send an execution request 
with that capability (see T in Figure [5]). In contrast, here when an operation 
request is sent in TS d we wait after sending an appropriate authorization request 
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fn{n,M)CiA = F', Clk' ~» F, Clk 
Req(K, M) 5f' Clk DReq(K, M) m 
ken fn(op,M) nA = F', Clk' ~* F, Clk 
Req(cert(F',fc, op, Clk'), M) Sf Xlk Req fc (op, Clk', M) 
fn(L,op,M) (1A = fceN fn(adm, M) H A = 

EOk(L, op, M) <Sf' clk EOk(L, op, M) AReq fc (adm,M) S( F '° k AReq fe (adm,M) 

j e n\i f n(op, M) n .A = 

CReq^opjM) ^ F ' clk (j/ m ) aj (m);m(i);M(mac({j, op, x), K?)} 

(FILE SYSTEMS) 

Vr G C. P r S[ F ' ak Q r fn(H, P )nA = 
NAFs(F,E,Clk,p) \n rSC P r 5f clk TFs(F,H,Clk,p)' )2 |II r6jC Q P 

(HONEST USERS) 

dom(cr) = dom(o" ) = X 
Vi. 3F', Clk', i G J, op. (F', Clk' •»-» F, Clk) A a'(x) = Clk' 

A T(x) = Cert(j, op) A a{x) = cert(F', i, op, Clk') 

Co- S 2 r ' FXIk TClro-' 

i£l P «Sj' F ' clk Q r(z) = Cert(i, op) 

M(c(x);P|CRe qi (op, C )) S 3 FXIk M(c(x);Q|TReq(c)) 

(TRUSTED CODE) 

P 5f clk Q P' S 2 r ' FXIk Q' Vr e C. Pr 5 3 FX ' k Q r 
(vieiai/3i5i)(P | P' \ U rS cPr) S' FXIk (u ie xa° /3°5°)(Q \ Q' | n r6£ Q r ) 

(SYSTEM CODE) 

P 5' F ' Clk Q Vj, JV. (3o-'. g = {*%} | a') N :jr, F ,ci k Export 
{un){vK M DK' M ){cj | P) 5 F,clk (vn)(yK- t ) (773(0) | (i/ j - 6N \ i iq| ? /3^ ? (5| ? )(Q | Tnas)) 

Figure 11: Simulation relation for Lemma[T6ll (_ ^ </>[_]) 
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iel fn(op,M) nA = F',C\k' ~» F, Clk 
Re qi (op,Clk',M) T 1 ' F,Clk Req(cert(F', fc, op, Clk'), M)" 1 
j G N\I f n(op, T,M)nA = 
Req 3 (op,r,M) T 1 ' F ' Clk (^c) aJ7(op, c); c(k;); [msg(fv).3 < r] /3 j? (k, Af) 
fn(L, op, M) n.4 = 



EOk(L, op, M) T 1 ' F,Clk EOk(L, op, M) 1,1 

fc € N fn(arfm, M) n A = 
AReq fe (adm,n) 7" 1 ' F ' clk AReq fc (adm, 
j G N\J fn(M) n A = 
TReq(M) T 1 ' F,Clk (i/c) 5J7(M,c);c(x);M(msg(as).3) 

(FILE SYSTEMS) 

Vr G C. P r T L ' FX ' k Q r f n(H, p) n .4 = 
TFS(F,H,Clk,p) |n rS£ P r Ti F ' clk NAFS^H.CIk.p)" 1 |n re£ Q r 
(HONEST USERS) 

dom(cr) = dom(fr') = X 
Vi. 3F', Clk', i G X, op. (F', Clk' ~> F, Clk) A a(x) = Clk' 

A r(a;) = Cert (i, op) A cr'{x) = cert(F', i, op, Clk') 

[Clra T 2 r ' F - Clk CV 

i£l P r 2 r ' F ' clk Q r(a;) = Cert(i, op) 
(i/c)(c(a;);P|TReq(c)) T 3 ' (vc)(c(x);Q | CReq^op,^) 
(TRUSTED CODE) 

P T F ' Clk g P' T 2 r ' F ' clk Q' Vr G £. P r % Qr 

(i> iex a°f3°8°)(P I P' I IWP r ) T' (v i exon0iSi)(yKAajK' u )(Q \ Q' \ U reC Qr) 

(SYSTEM CODE) 

P T' Q 

(un)(a | P) T (un)(a \ (u ]et , Ax a, ? f3 J? S j? )(Q | t?s S )) 

Figure 12: Simulation relation for Lemma[T6l2 (_ =^ t/>[_]) 
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fn{K,M)nA = j e N\I in{op,M) C)A = F', Clk' •<** F, Clk 

DReq(K,M)' 72 «( F ' Clk Req(/s,M) ]3°~ ; (op, Clk', M) «( F ' Clk Req(cert(F',j, op, Clk'), M) 

j£ff\I fn(op,Af)n.4 = F',Clk' F, Clk 
DReq J (op,Clk',M)' )1 ®' 72 Z^ F ' clk Req(cert(F', j, op, Clk'), M) 
j € N\T fn(op,M)r\A = F',Clk' -w F,Clk 
(uc)(c(x); [msg(a;).3 < Clk'] J~(x,M) | CReq^op, c)) W; F '° k Req(cert(F',j, op, Clk'), M) 
fn(op,A/) n.4 = F', Clk' ~» F, Clk AT = mac((j, op, Clk'), K?) 
(vc)(c(x); [msg(a;).3 < Clk'] 0~{x, M) j c(N)) W{ F ' clk Req(cert(F', j, op, Clk'), M) 
j € N\I fn(op,Af) 0.4 = F', Clk' -w F, Clk 
ft7(mac(0', op, Clk'), K ? ),M) W{ F,Gk Req(cert(F',j, op, Clk'), M) 

ifceN fn(op, M) n„4 = F', Clk' -w F, Clk 
Req(mac((fe, op, Clk'), F/ ? ), M) W( FXIk Req(cert(F', k, op, Clk'), M) 
f n(L, op, M) nA — 
EOk(L, op,A/) W( FXIk EOk(L, op, M) 
j € N\X f n(op, A/) C)A = 
(vm) a° 7 {m);m(x); M (mac((j, op, x), F ? )) W^ clk CReq^ (op, Af) 
j6N\I fn(op,Af) n.4 = F', Clk' ~* F, Clk 
(i/m) (m(:r); Af(mac((j, op,x),K^)) | m(Clk')) W; F ' Clk M(cert(F', fc, op, Clk')) 

fn(odm, M) n„4 = 
AReq fc (arfm,A/) W( F CIk AReq fc (arfm, M) 

(FILE SYSTEMS) 

Vr G £. P r ^ F ' Clk Q r fn(H, p) n A = 
Tnas" 2 I tTS Sm<SV2 I NAfs(F, B, Clk, p)* 11 | n reC F,. wf' clk nafs(F, B, Clk, p) | LT re£ Q r 

(HONEST USERS) 

\C] r = C° 

Vs. zedom(o-) 3F', Clk', i el, op. (F', Clk' F, Clk) 

A F(x) = Cert (i, op) A cr(a;) = cert (F', i, op, Clk') 

Co- ap 5 * Co- 

i € I T{x) = Cert(i, op) P W 2 r ' FXIk Q 
(vc)(c{x);P ICReq^c)) W 3 F ' Clk (i/c)(c(x); Q | CReq,(op,c)) 
(TRUSTED CODE) 

F < Xlk Q P' Q' Vr e C. P t U^ C,k Qe 

(uiexctiPiSiXvKMDK'MXP | P' | n rec Pr) W FXIk (v iex aiPi6i)(Q \ Q' | n Pe£ Q r ) 

(SYSTEM CODE) 

F ^' F ' Clk g Vx, TV. (3o-'. a = {%} | a') 7V :^ F ,qk Export 
(i/n)(i/i<:?) (773(0-) I (^ jeN \ T a° ? /3° ? i5° ? aj ? /3j ? 5j ? ) F) W (un)(vK M DK' M ){a \ Q) 

Figure 13: Simulation relation for Lemma[T6l3 (0[t/i[_]] =<! _) 
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jeN\l ±n(op,T,M)nA- 



{uc)af;(op,c);c(K);[msg(K).3<T]^(K,M) V( FXIk Req^op, r, M) 

jeN\I f n(op, r, M) n A = N = mac((j, op, x),K?) 

(vc)(c(K);[m S g( K ).3<T]P~{K,M) \ (i/m)a?7(m>;m(z);B(JV)) Vf' clk Req^op.r.M) 

;GN\I f n(op, r, M) n .A = JV = mac((j, op, x),Kt) 

(i/c)(c(k); [msg(«).3 < r] &7(/t, M) | (i/m)(m(a:);c(JV) | TReq(m))) V( FX ' k Req., (op, t,M) 

jGN\T fn(op,T,M) n A = F', Clk' ~> F, Clk TV = mac({j, op, Clk'), K ? ) L = perm(F', j, op) 

(i/c)(c(k); [msg(/e).3 < r] /3~7<k, M> | (um)(m(x);c{N) | m(Clk'))) V{ F ' clk [Clk < r] EOk(L, op, M) 

j G N\T f n(op, t, M) n A = F', Clk' F, Clk L = perm(F', j, op) 

M(c(k); [msg(«;).3 < r] ^{k;, M> | c<mac(<j, op, Clk'), AT?))) V( FXIk [Clk < r] EOk(L, op, M) 

jeN\X fn(op,M)CiA = F', Clk' F, Clk j G N\X fn(op, M) nA = F', Clk' ~> F, Clk 
TV = mac({j, op, Clk'), F?) L = perm(F', j, op) TV = mac((j, op, Clk'), K?) L = perm(F' , j , op) 

P~{N,M) V^ FXIk EOk(L,op,M) DReq(7V,M)' 7lffl ' ?2 V( FXIk EOk(L, op, M) 

j G N\F fn(op, M)C\A = 
F', Clk' F, Clk L = perm(F',j, op) fn(op, M) fl^ = 



/3? 7 (op, Clk',M) V( FXIk EOk(L, op,M) EOk(L, op, M) V( F ' clk EOk(L, op, M) 
fn(adm, M) <1 A = j G N\I f n(M) f)A = 



AReq k (adm,M) V" ' UK AReq k (adm, M) (vc) aj^{M, c); c{y); M{msg(y).3) V*' u * TReq(M) 

j G N\J fn(M) n A = 
M( C (y);M<msg(i/).3) | (m) o°^(m); m(x); c(mac((j, M, x),Kv))) V( FXIk TReq(M) 

j e N\J fn(M) r\A = 

M( C (j/);M(msg(y).3) | (^(m^); c{mac({j, M,x),K,)) | TReq(M))) V( FXIk TReq(M) 
j G N\J fn(M) n A = Clk' < Clk 
(i/c)(c(y);M(msg(y).3) j (fm)(m(i);c{mac({j, M, x),K?)) | m(Clk'))) V( F ' clk m(Clk') 

j G N\T fn(M) n A = 
( I /c)(c(y);M(msg(y).3> | c(mac(0 - , M, Clk'), F ? ))) Vf xik M(Clk') 
(FILE SYSTEMS) 

Vr G £. F r V( FXIk Q r f n(H, p) n A = 
T?^ 8 " 1 I tSls" 19 " 2 I TFs(F,H,Clk,p)- | n re£ P r V FXIk TFs(F,H,Clk,p) | n re£ Q r 

(HONEST USERS) 

Vas. x G dom(o) => 3Clk',i G X, op. Clk' < Clk A I\a;) = Cert(i, op) A 0(2; ) = Clk' 

[Giro V 2 r ' FXIk \C]ra 
i G 1 F(x) = Cert(i, op) F V^' FXIk Q 
(uc)(c(x); P | TReq(c)) V 3 FXIk (i/ C )( C (a;);Q | TReq(c)) 

(SYSTEM CODE) 

F V FXIk Q F' V 2 F ' c,k Q' Vr G C. Pi V 3 F ' clk Q< 
F" = (v i£ za° (3° 5°)(isK->)(P \ P' | n reC P r ) Q" = (^ gJ a°/3°^)(Q | Q' \ U reC Qr) 

(yn)(o | (v i a\ia°,ftVj°,Qj ? /3,,(5 i ,) F") V (i/n)(<r | Q") 



Figure 14: Simulation relation for Lemma[T7l(^[o!)[_]] ^ _) 
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in NAS d (see T in Figure [b2l>; we continue only when that operation request 
in TS d is processed, when we obtain a capability in NAS d , send an execution 
request with that capability, and process the execution request. 

But why wait? Suppose that the operation request in TS d carries a time bound 
oo; now if we obtain a capability in NAS d before the operation request in TS d 
is processed, we commit to a finite time bound, which breaks the simulation. 

• As before, cf>[ip] forces a fresh capability to be acquired for every execution re- 
quest by filtering execution requests in NAS d through TS d and back. When 
an execution request is sent in NAS d under cf>[ip] we send an execution request 
with the same capability in NAS d (see IA in Figure fT3l. But under <f>[ip] a fresh 
capability is obtained and the execution request is sent again with the fresh capa- 
bility. If the capability in the original request expires before the fresh capability, 
the simulation breaks. Fortunately operation requests in TS d carry time bounds, 
so we can communicate this expiry bound through TS d . In fact there seems to 
be no way around this problem unless time bounds can be specified in operation 
requests in TS d \ 

By PropositionfTOlwe have: 

Lemma 16. For any F, p, and C, 

L {v iez aiPi5i){C (vKmdK' m )kafs(F,0,O,p)) 

1 <P[(viexa°f3°8°)({C] \rvs(\F],0,O, \p\))} 

2. (v ieI a°p?5°)(\C] |TFS([F1,0,O,M)) 

r< V[(^6xa*M)(C| (vKmdK' m )kafs(F,0,Q, P ))] 

3. ( t>[^[{viexaiPi8 i ){C\{vK M DK' M )nA¥s{F,0^,p))}} 

< {viz X aipi5i){C | (vK M dK' m )nafs(F, 0, 0, p)) 

So by Proposition[7] H is secure. 

Further we prove that the relation V in Figure[l4]is also included in the simulation 
preorder. By Proposition[lO]we have: 

Lemma 17. For any F, p, and C, 

m(^xa°P°S°)(\C] I TFs(rFl,0,O, M))]] 

d (v ieI aZfiSZ)(\C] |TFs(rFl,0,O,M)) 

So by Lemmas [T6l 1-2 and Corollary[8] 1Z is safe and fully abstract. 

7 Designing secure distributed protocols 

In the preceding sections, we present a thorough analysis of the problem of distributing 
access control. Let us now apply that analysis to a more general problem. 

Suppose that we are required to design a distributed protocol that securely imple- 
ments a specification. (The specification may be an arbitrary computation.) We can 
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solve this problem by partitioning the specification into smaller computations, running 
those computations in parallel, and securing the intermediate outputs of those compu- 
tations so that they may be released and absorbed in any order. In particular, we can 
design NS d+ by partitioning IS into access control and storage, running them in 
parallel, and securing the intermediate outputs of access control as capabilities. The 
same principles should guide any such design. For instance, by (I© and (I© interme- 
diate outputs should not leak information prematurely; by (RO and (I© such outputs 
must be timestamped and the states on which they depend must not change between 
clock ticks; and by (A|5j the specification must be generalized with time bounds. 

Computation as a graph We describe a computation as a directed graph G(V,£ ). 
The input nodes, collected by Vj C V, are the nodes of indegree 0. The output nodes, 
collected by V C V, are the nodes of outdegree 0. Further, we consider a set of state 
nodes V s C V such that V, (~l V s = 0. As a technicality, any node that is in a cycle or 
has outdegree > 1 must be in V s . 

Nodes other than the input nodes run some code. Let M. contain all terms and 
C be a strict total order on V. We label each v G V \ (V,; U V s ) with a function 
X v : M in{v) -> M, and each v G V s with a function A„ : M in{v) x M -> M. 
Further, each state node carries a shared clock, following the midnight-shift scheme. 

A configuration (cr, r) consists of a partial function a : V — > M such that dom(er) D 
V s , and a total function r : V s — > N. Intuitively, a assigns values at the state nodes 
and some other nodes, and r assigns times at the state nodes. For any v G V \ Vi, the 
function A„ outputs the value at v, taking as inputs the values at each incoming u, and 
the value at v if v is a state node; further, if such u ^ V s , the value at u is "consumed" 
on input. Formally, the operational semantics is given by a binary relation over 
configurations. 

veV\(V,U V s ) Vfc G l..in(u). (u fc , v) e £ A a(u k ) = t k 

Ui C . . . C er~ = cr|v s U(V\{«i,. ..,ti la(l ,,} 

(cr, t) ~* (cr - [v (t i , . . . , t in{v) )] , r) 

v £ V s t(v) = Clk a(v) = t 
Vfc G l..in(u). (Uk,v) G £ A cr(ufe) = tk 
til C ... C er~ = cr|v,u(V\{ui,...,« taW } 

(cr, r) (cr~[v A„(tl, . . .,tin(„),t)],T[u ' ^ Clk + 1]) 

As usual, we leave the context implicit; the adversary is an arbitrary context that can 
write values at Vi, read values at V , and read times at V s - 
For example, a graph that describes IS d+ is: 

•l * *2 < " *4 * *6 '' *7 ► »8 

I T 

•3 »5 

Here V l = {»i, » 5 }, V Q = {. 3 , . 8 }, V, = {* 2 , * 4 , * 7 }, and V = V, U V a U V, U {. 6 }. 
Intuitively, *2 carries accumulators, and »i and »3 carry inputs and outputs for access 
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modifications; *4 carries access policies, and »@ carries access decisions; *7 carries 
stores, and #5 and •§ carry inputs and outputs for store operations. We define: 



A* 2 ((fc,6»),F, (_,£}) = exec(perm irfe e ,6i,S) 

A. 3 ((JV,S» = TV 

A* 4 «_,S>,_) = S 

X. 6 (F, (k, op)) = (o P ,perm Fk op ) 

\* 7 {(op,L), (_,/>)) = exec(L,op,p) 

X. s ((N,p)) = N 



Distribution as a graph cut Once described as a graph, a computation can be dis- 
tributed along any cut of that graph. For instance, IS d+ can be distributed along the 
cut {(»6, *7)} to obtain NS d+ . We present this derivation formally in several steps. 



Step 1 For each v <G V, let S(v) C V s be the set of state nodes that have paths 
to v, and I(v) C Vi be the set of input nodes that have paths to v without passing 
through nodes in V s . Then G(V, £) can be written in a form where, loosely, the values 
at I(v) and the times at S(v) are explicit in a(v) for each node v. Formally, the 
explication of G is the graph G(V, £) where V = V U {v \ v G V{\ U {ii | u e V } and 
£ = £ U {{v, v)\veVi}U {(u, u)\uG V }. We define: 

v eVi v e V 



X v {t) = (t,t) Xa(.,t) = t 
veV\{V,uV s ) K(t 1 ,...,t Mv) ) = t 

X v ({h,h), . . . , {I±n(v),t in ( v ))) = ({h ■ ■ ■ hn(v)),t) 

veV s a(v) = (C\k,t) X v (t 1 ,...,t in(v) ,t) = t' 
X v ((.,t 1 ),...,(.,t in{v) ),(C\k,t)) = (C\k + l,t') 
This translation is sound and complete. 

Theorem 18. G is fully abstract with respect to G. 

For example, the explication of the graph for IS + is: 

•l > *2 < 1 *4 > »6 > *7 ► »8 

T I T I 



•3 »5 

Here cr(» 6 ) is of the form ((k, op, Clk), (op, perm F k op )) rather than (op, perm F k op ); 
the "input" a (•5) = (fc, op), the "time" t(* 4 ) = Clk, and the "output" (op, perm F fe op ) 
of an access check are all explicit in a(»e). A capability can be conveniently con- 
structed from this form (see below). 



34 



Step 2 Next, let £o be any cut. As a technicality, we assume that £q l~l ((Vi U V s ) x 
V) = 0. The distribution of G along £ is the graph G $ (V $ ,£ $ ), where V s = V U 
{v | (v, _) G £0} U {v $ | («, _) G M and £ $ - {£ \ £ ) U {(¥, v $ ) \ (v, _) G £ } U 
{(v $ , it) I (w, u) G £o}- Let i4T„ and £"„ be secret keys shared by v and u $ for every 
(v, _) G £o- We define: 

(w,_)g£ A„ (ti,..., *in(«)) = (*>*') mis fresh 
A*(*i, . . . , t in{v) ) = mac((t, {to, t'} Ev ) 7 K v ) 

(v, _) G £o t(S(v)) is included in t 
A*,((i,mac((*,{_,t'} B J,iif„))) = (VO 

A* = 

Intuitively, for every (v, _) G £o> w$ carries the same values in G s as t> does in G; 
those values are encoded and released at v, absorbed at v, and decoded back at v®. For 
example, the distribution of the graph for IS along the cut {(»6, *7)} is: 

•l > *2 < " *4 ^ 

T I 

•l »3 

I 

•3 

This graph describes a variant of NS d+ . In particular, the node now carries a ca- 
pability of the form mac(((fc, op, Clk), {to, (op, perm Ffcop }}_B >6 ), Jf. 6 ), that secures 
the input, time, and output of an access check. 

Step 3 Finally, G is revised following (AE). The revision of G along £q is the graph 
G#(V # ,£ # ), where V* =VU{/ | («,_) e£ }and£# =£u{(v#,v) | («,_) G 
£o}- We define: 

M_gjo t(S(«))<T 

A„ 1 , ■ ■ ■ , *in(«) i 7 1 ) = A„ (ti , . . . , t in („) ) 

^V\V, (v,-)<t £o 
A# = A„ 

Intuitively, for every (u, _) G £o, progress at v requires that the times at S(v) do not 
exceed the time bounds at u*. For example, the revised form of the graph for IS + is: 

•l > *2 < 1 *4 > '6 ► *7 * »8 

i / r 

•3 •* # 5 

Here »f carries a time bound T, and A^ 6 (i* 1 , (fc, op),T) = A. 6 (i* 1 , (fc, op)) if r(*4) < 
T. 

We prove the following correctness result. 



•6 


*7 — 




T 


t 


i 


•5 


"6 


•a 


T 


I 




•5 


•(> 
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Theorem 19. G $ is fully abstract with respect to G#. 

By Theorem[T9] the graph for NS d+ is fully abstract with respect to the revised graph 
for IS* . 

Similarly, we can design NS S from IS S . The induced subgraph of IS d+ without 
{•i>*2, •3 ) *4} describes IS S . We define A. 6 ((fc, op)) = (op,perm Ffc ) for some 
static F. Distributing along the cut {(*6,*7)}, we obtain the induced subgraph of 
NS d+ without {•!, •i,*a, «3, »3,*4}. This graph describes a variant of NS S , with 
tr(»6) of the form mac(((fc, op), {m, (op,pexm F k op )}e, 6 ), K, 6 ). (Here capabilities 
do not carry timestamps.) By Theorem [19] the graph for NS S is fully abstract with 
respect to a trivially revised graph for IS S , where \f 6 ((k, op), ()) = X, 6 ((k, op)). 

8 Conclusion 

We present a comprehensive analysis of the problem of implementing distributed ac- 
cess control with capabilities. In previous work, we show how to implement static 
access policies securely iflOl and dynamic access policies safely ifTTl . In this paper, 
we explain those results in new light, revealing the several pitfalls that any such de- 
sign must care about for correctness, while discovering interesting special cases that 
allow simpler implementations. Further, we present new insights on the difficulty of 
implementing dynamic access policies securely (a problem that has hitherto remained 
unsolved). We show that such an implementation is in fact possible if the specification 
is slightly generalized. 

Moreover, our analysis turns out to be surprisingly general. Guided by the same 
basic principles, we show how to automatically derive secure distributed implementa- 
tions of other stateful computations. This approach is reminiscent of secure program 
partitioning [22], and investigating its scope should be interesting future work. 

Acknowledgments This work owes much to Martin Abadi, who formulated the orig- 
inal problem and co-authored our previous work in this area. Many thanks to him and 
Sergio Maffeis for helpful discussions on this work, and detailed comments on an ear- 
lier draft of this paper. It was Martin who suggested the name "midnight-shift". Thanks 
also to him and Cedric Fournet for clarifying an issue about the applied pi calculus, 
which led to simpler proofs. 

References 

[1] M. Abadi. Protection in programming-language translations. In ICALP' 98: In- 
ternational Colloquium on Automata, Languages and Programming, pages 868- 
883. Springer, 1998. 

[2] M. Abadi, C. Fournet, and G. Gonthier. Secure implementation of channel ab- 
stractions. In Thirteenth Annual IEEE Symposium on Logic in Computer Science, 
pages 105-116, 1998. 



36 



[3] M. Abadi, C. Fournet, and G. Gonthier. Authentication primitives and their com- 
pilation. In POPL'OO: Principles of Programming Languages, pages 302-315. 
ACM, 2000. 

[4] M. Abadi and L. Lamport. The existence of refinement mappings. Theoretical 
Computer Science, 82(2):253-284, 1991. 

[5] M. Abadi and R. Needham. Prudent engineering practice for cryptographic pro- 
tocols. IEEE Transactions on Software Engineering, 22(1):6— 15, Jan. 1996. 

[6] M. Backes, C. Cachin, and A. Oprea. Secure key-updating for lazy revocation. 
In ESORICS'06: European Symposium on Research in Computer Security, pages 
327-346. Springer, 2006. 

[7] M. Backes and A. Oprea. Lazy revocation in cryptographic file systems. In SISW 
'05: Security in Storage Workshop, pages 1-11. IEEE, 2005. 

[8] B. Blanchet and A. Chaudhuri. Automated formal analysis of a protocol for se- 
cure file sharing on untrusted storage. In S&P'08: Proceedings of the 29th IEEE 
symposium on Security and Privacy, pages 417^431. IEEE, 2008. 

[9] R. Canetti. Universally composable security: a new paradigm for cryptographic 
protocols. In FOCS'01: Foundations of Computer Science, pages 136-145, 2001. 

[10] A. Chaudhuri and M. Abadi. Formal security analysis of basic network-attached 
storage. In FMSE'05: Formal Methods in Security Engineering, pages 43-52. 
ACM, 2005. 

[11] A. Chaudhuri and M. Abadi. Formal analysis of dynamic, distributed file-system 
access controls. In FORTE'06: Formal Techniques for Networked and Dis- 
tributed Systems, pages 99-1 14. Springer, 2006. 

[12] K. Fu, S. Kamara, and Y. Kohno. Key regression: enabling efficient key distribu- 
tion for secure distributed storage. In NDSS'06: Network and Distributed System 
Security, 2006. 

[13] H. Gobioff, G. Gibson, and J. Tygar. Security for network attached storage de- 
vices. Technical Report CMU-CS-97-185, Carnegie Mellon University, 1997. 

[14] S. Goldwasser and M. Bellare. Lecture notes in cryptography, 2001. See 

|http : / /www .cs.ucsd. edu/users /mihir /paper s/gb . html] 

[15] S. Halevi, R A. Karger, andD. Naor. Enforcing confinement in distributed storage 
and a cryptographic mo del for access control. Cryptology ePrint Archive, Report 
2005/169, 2005. See http : //eprint . iacr . org/2 005/1 69| 

[16] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus: scalable 
secure file sharing on untrusted storage. In FAST'03: File and Storage Technolo- 
gies, pages 29^12. USENIX Association, 2003. 



37 



[17] S. Maffeis. Dynamic Web Data: A Process Algebraic Approach. PhD thesis, 
Imperial College London, August 2006. 

[18] D. Mazieres and D. Shasha. Building secure file systems out of byzantine storage. 
In PODC'02: Principles of Distributed Computing, pages 108-1 17. ACM, 2002. 

[19] R. Milner. Fully abstract models of typed lambda-calculi. Theoretical Computer 
Science, 4(1): 1-22, 1977. 

[20] R. Milner. The polyadic pi-calculus: a tutorial. In F. L. Bauer, W. Brauer, and 
H. Schwichtenberg, editors, Logic and Algebra of Specification, pages 203-246. 
Springer- Verlag, 1993. 

[21] R. D. Nicola and M. C. B. Hennessy. Testing equivalences for processes. Theo- 
retical Computer Science, 34(l-2):83-133, 1984. 

[22] S. Zdancewic, L. Zheng, N. Nystrom, and A. C. Myers. Secure program parti- 
tioning. ACM Trans. Comput. Syst., 20(3):283-328, 2002. 



38 



